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METHOD AND APPARATUS FOR PROCESSING 
AND REVIEWING ADVERTISEMENT SUBMISSIONS 
FOR CONTENT AND CONFORMITY 

5 

CROSS REFERENCE TO RELATED APPLICATIONS 

This application claims the benefit of United States provisional patent 
application No. 60/147130, filed August 4, 1999, the entire disclosure of 
which is hereby incorporated herein by reference. 

io 

FIELD OF THE INVENTION 

The present invention broadly concerns publication of advertisements 
on Web pages and more particularly concerns a system and method for 
receiving, processing, and reviewing advertisements for content and 
1 5 conformity for embedding in a Web page published over the Internet. 

BACKGROUND OF THE INVENTION 

Web pages frequently include embedded advertisements. Different 
Web pages have different requirements for placement of an advertisement on 

20 the page. For example, the requirements for placement of an advertisement 
on a Web page may vary in file type, file size, number of characters, number 
of images, and Java, or JavaScript facilities. An advertiser or advertising 
agency may produce a single advertisement which the advertiser or agency 
would like to publish in many different web pages. However, such an 

25 advertisement might be compatible with some web pages and not others. For 
example, the advertisement might be 4000 characters in size and the Web 
page advertisement space may only be able to accommodate 3000 
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characters in size. This discrepancy in size would result in the advertisement 
not being properly displayed, and the advertiser or agency would not be 
aware of the problem until the advertisement is actually published and viewed 
by the advertiser or agency. 

5 

To avoid such problems, certain tasks are implemented manually by 
production facilities for Web pages. These tasks include having a person 
review the advertisement before it is published on a Web page to verify that 
the advertisement meets the requirements of the page. The person may 

io receive advertisements on a disk sent by mail or may receive advertisements 
through e-mail delivery. Upon receiving the advertisements, the person would 
have to load the files into a computer system and identify and remove all 
necessary advertisement attachments and make copies of each. The person 
would also have to manually calculate the file size, number of lines, number of 

is characters, number of images, check for Java and JavaScript programming 
code, and remove unnecessary or incompatible code or add necessary code. 
The person would then have to manually compare the advertisement 
properties to the particular Web site parameters in which the advertiser or 
agency wants to publish the advertisement. Manual application of these tasks 

20 can result in errors and reduced capacity for hosting advertisements. The 
tasks involved in processing advertisements for conformance to a particular 
web site is both tedious and time consuming. 
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Accordingly, there is a need for a system that automates the process 
of receiving, processing, and reviewing advertisements for content and 
conformity for embedding in a Web page published over the Internet. 



5 SUMMARY OF THE INVENTION 

The present invention satisfies the above described needs by providing 
a method and a system for receiving, processing and reviewing 
advertisements for content and conformity to requirements for embedding in a 
Web page published over the Internet. The method includes receiving a 

io submission from an advertiser or advertising agency. The submission may 
contain multiple file attachments, html code, and information about where to 
locate a creative asset on the World Wide Web. The submission is searched 
for creative assets by the advertisement ,management system. The creative 
assets may be text code, image code, and rich media code that are 

is processed to form and advertisement. Rich media is a media type such as 
JPEG, GIF/animated GIF, Enliven, InterVU, Comet Cursors, VRML, 
Shockwave, and Flash. The creative assets are modified so that they are in a 
form that is appropriate for publication on an existing Web page, and are 
compared to Web site guidelines for conformity to the guidelines as part of an 

20 approval process. 

The advertisement management system includes a front-end system 
for providing the user with the ability to control the system. The front-end 
system uses a standard web browser as a user interface to the advertisement 
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management system. A mail system receives, transmits, and processes 
submissions sent to it by an advertiser or an advertising agency. A business 
system coupled to the front-end system and the mail system modifies the 
creative asset and compares it to Web site guidelines for conformity as part of 

5 the approval process. 



BRIEF DESCRIPTION OF THE DRAWINGS 

FIG 1. is a block diagram of a preferred advertisement management 
system. 

io 

FIG 2. is a flowchart outlining the general assembly process of a rich 
media advertisement. 

FIG 3. is a flowchart illustrating in greater detail steps 62 through 72 of 
15 FIG 2 according to one embodiment of the present invention. 

FIG 4. is a flowchart illustrating a front-end pickup URL process. 

FIG 5 is a flowchart illustrating a back-end pickup URL process. 

20 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

A preferred embodiment of the present invention is directed to an 
advertisement management system for receiving, processing, and reviewing 
advertisements for content and conformity for publication on the World Wide 

4 
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Web. The advertisement management system automates the process of 
receiving, reviewing and processing creative assets for publication on Web 
pages. Submissions are sent by advertisers or advertising agencies through 
e-mail to the advertisement management system for processing. The 
5 submissions include creative assets, which are elements that will be 
processed and combined to form a Web page advertisement The 
submissions may also contain messages that include a date, a sender's name 
and attachments or images. Additionally, the submission may include multiple 
file attachments, html code, or information about where to locate an 
io advertisement on the World Wide Web. When a submission is received by 
the advertisement management system, it is separated into components, 
where the components may be multiple file attachments (creative assets), 
text. etc. The advertisement management system processes the creative 
assets and modifies them, if necessary, and compares them to Web page 
is guidelines for conformity. The preferred advertisement management system 
provides for the creation of filters and ad models which can serve as Web 
page guidelines. The system provides the ability to review new advertisement 
submission for content and for conformity to the ad models 

20 A block diagram of an advertisement management system formed in 

accordance with a preferred embodiment of the present invention is illustrated 
in figure 1 . The advertisement management system preferably includes a 
front-end system 2, a back-end system 28, a database 6. an adapter system 
8, and an ad server database 10. The front-end system 2 is coupled to the 
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back-end system 28 and the database 6. The front-end system 2 provides a 
user interface to the advertisement management system. The back-end 
system 28 receives submissions and processes them into advertisements and 
stores them in the database 6. Data for the advertisement management 
5 system is stored in the database 6. The adapter system 8 is coupled to the 
database 6 and ensures that data stored in the database 6 is transferred to 
the ad server database 10, which stores the advertisements for use by an ad 
server. 

io Preferred embodiments of the present invention facilitates preparing 

rich media advertisements for use on web pages. The front-end system 2 
preferably includes at least one web browser 12. a http web server 14, and 
Java sen/lets 16. The web browser 12 provides for user access to the 
advertisement management system. There are several commercially 

is available web browsers, however, the preferred web browser 12 is Netscape 
Navigator from Netscape Communications. The web browser 12 provides the 
user with a window and various controls through which data from the web 
server 14 can be viewed and navigated. The user selects advertisement 
management system features and options via the web browser 12. Using the 

20 web browser 12, the user may enable different filters to apply to a selected 
creative asset and may review the creative asset for content and attributes. 

The http web server 14 provides the hardware for communication 
between the web browser 12 and the back-end system 28. The user 
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commands executed at the web browser 12 are transferred through the http 
web server 14. The http web server 14 transmits and receives data between 
the web browser and the back-end system 28 and the database 6. The data 
provided by the web server 14 will be in the form of pages of data that can be 
5 examined using typical browser software. The web server 14 preferably 
includes Java servlets 16, which in the representative embodiment is the 
common gateway interface (CGI) program. The Java servlets 16 are software 
objects that control the retrieval and presentation of data onto the web 
browser 12, from the database 6, and which communicates with the back-end 

io system 28. The CGI program is a program interface between the web server 
14 and the back-end system 28 and the database 6. The CGI program lets 
the back-end system 28 process html forms and other data coming form the 
web browser 12, and then lets the back-end system 28 send responses back 
to the web server 14, which is delivered to the web browser 12. A main 

is purpose of this program is to provide web-to-database access for the html 
interface. There is also logic in the program to process the commands 
selected by the user (i.e. approving banners, sending rejection e-mail). HTML 
templates served up by the CGI program are the main interface to the back- 
end system 28 and the database 6. Generally, the CGI program fills out the 

20 html templates and returns them to the web browser 12. In particular, the CGI 
program selects e-mail messages from an e-mail table in the database 6, and 
displays them to the user. 



7 



WO 01/1 1516 PCTAJS00/20765 
The back-end system 28 preferably includes three systems, each of 
which functions as five daemons and together function as a multithreaded 
application running in the background as a daemon process. The e-mail 
system 4 functions as a post office protocol (pop) checker daemon, a simple 

5 mail transfer protocol (smtp) checker daemon and an e-mail sender daemon . 
The ISD/Validator system 26, functions as an infoscanner daemon (ISD) and 
a validator daemon (validator). Each of these daemon functions run as an 
independent thread of execution within the daemon process. All five threads 
may be running within the daemon process at the same time and any of the 

io threads may be enabled or disabled from the user screen of the 

advertisement management system interface. The back-end system 28 
receives e-mail from agencies and/or advertisers through the simple mail 
transfer protocol (smtp) or post office protocol (pop3) e-mail system 4. The 
smtp is a TCP/IP standard protocol for sending e-mail between servers. The 

is pop is a standard protocol that provides for client mail-reading programs to 
retrieve messages from a mail server. The e-mail system 4, includes the pop 
checker daemon which polls remote pop3 accounts for incoming e-mail 
submissions. The smtp checker daemon polls local smtp accounts and 
folders for incoming e-mail and downloads them into local directories in the 

20 database 6. The e-mail system 4 also includes an e-mail sender daemon 
which sends out e-mail to advertisers with assets that are rejected. The 
ISD/validator system 26, includes the ISD daemon which parses downloaded 
e-mail messages for assets and scans each asset for various properties, and 
matches the asset against user defined and industry standard configured 
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placement groups. The ISD/validator system 26 also includes the validator 
daemon which synchronizes the assets that are approved by the user and 
sends them to an ad server. 

5 More specifically, the back-end system 28 includes the pop checker 

daemon that is responsible for retrieving e-mail from a pop server, located 
outside the advertisement management system. The pop checker logs into 
the e-mail account server and retrieves any new e-mail that has come into the 
e-mail account server. The pop checker, utilizing e-mail processors 20. 

io extracts any zip files into individual files and reattaches the individual 

components to the e-mail. The e-mail and the attachments are stored in the 
database 6 file system under specific reference tables. After saving the e- 
mail and the components, the pop checker pings (Packet Internet Groper) the 
ISD/validator 26 for further processing. The Packet Internet Groper is a 

is program used to test reachability of a destination by sending it an echo 

request and waiting for a reply. The smtp checker daemon is responsible for 
handling the e-mail that comes in by way of the smtp accounts. The smtp 
checker performs the same functions that the pop checker performs, with the 
exception that the smtp checker includes the ability to log into smtp compliant 

20 mail boxes, which are mainly used for internal system e-mail. The main 

responsibilities of the pop checker daemon and the smtp checker daemon are 
to receive all e-mall sent to the advertisement management system and to 
extract all of the attachments that come in with the e-mail. The e-mail is 
separated into components, where the components may be multiple file 
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attachments that are advertisements (creative assets), html code, or text that 
includes information about where to find the creative asset on the Web. The 
text may include a universal resource locator (URL) of which the user can use 
the web browse 12 to access the particular Web page and obtain 
5 advertisements posted on the page. The attachments are put into a list and 
an attachment list is created along with an instruction list. The e-mail sender 
daemon, located within the e-mail system 4, is responsible for sending e-mail 
to the outside world from the advertisement management system. 

io Preferably, the business system 22 includes Java objects 24 and the 

ISDA/alidator 26, which includes the infoscanner daemon (ISD) and a 
validator daemon. One process performed by the Java objects 24 is a work 
queue. The work queue identifies a status of each submission, such as new. 
processed, deleted, other, and permits the user to view other attributes of the 

is submission. The work queue may sort by subject or date and may select a 
single group or all submissions for forwarding or deleting. The work queue 
may also forward the submission for processing and may forward 
submissions for group processing. The Java objects 24 also controls the 
submission process of advertisements to the ISD/validator 26. This interface 

20 allows the user to process every aspect of the submission by providing a 
display screen that allows the user to select various options. The screen that 
is displayed contains a formatted view of the e-mail, options for searching for 
other submissions and advertisements, the ability to add an html asset (html 
submission), addition of a text asset (text submission), or pick-up an asset 
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from a web location (pick-up URL), select an advertiser and/or campaign, 
process each asset (create/edit, reject, ignore, duplicate), and process the 
advertisement. 

5 The infoscanner daemon (ISD), located within the ISD/Validator system 

26, is the main engine of the back-end system 28. The ISD reads the e-mail 
that enters into the system through pop checker 18 or smtp checker 18. The 
e-mail is parsed and different types of ads are constructed out of the 
submission. Each ad is validated against a set of rules and the result is 

io stored in the database 6. The ISD applies passive validation rules (ad 

models) and applies active rules (filters) that modify the html ads that come 
into the system. The active and passive rules can be configured through the 
front-end system 2 and stored in the database 6. After the ISD has completed 
the processing of the advertisements, the advertisements become available 

is for user interaction. 

The validator daemon, located within the ISD/Validator system 26 
handles submissions from the front-end system 2, unlike the ISD that 
handles submissions that come in through the e-mail system 4. The front-end 
20 system 2, through the pick-up URL functionality, picks up ads from a web 
page and submits it to the validator. The information transferred to the 
validator from the front-end system 2, is conveyed through a ping-string that 
informs the validator as to the type of submission and the location of the 
asset retrieved by the pick-up URL process. The validator applies the ad 
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models and filter rules to the advertisements that come in by the front-end 
system 2. The ISD applies the ad models and filter rules to the 
advertisements that come in by the e-mail system 4. 

5 The database 6 is coupled to the back-end 28 and makes use of 

standard database technology to manage creative assets, campaigns, and 
account information. The database 6 stores modifiable records with 
information about the e-mail accounts used for creative submissions, 
submissions and client correspondence, ad models, filters, and templates 
io used to preprocess creative asset, system user information, and 

advertisements, agencies, advertisers, and campaigns. Data definition and 
manipulation is optimized through the use of the Structured Query Language 
(SQL). 



is The adapter 8 is the interface between the database 6 and the ad 

server database 10. Any changes in the advertisement management system, 
such as an ad being approved and submitted, are synchronized with the ad 
server database 10 by the adapter 8. The adapter 8 consists of three 
systems: an extract system, which pulls the changed data from the database 

20 6; a map or transform system, which changes the format of the data from the 
advertisement management system data model to the ad server data model; 
and a store system, which inserts, updates or deletes the mapped data on 
the ad server. These functions ensure that the ad server database 10 is 
updated with any new information generated by the advertisement 
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management system. 

Figure 2 illustrates the general flowchart for processing rich media 
code by the ISDA/alidator system. Preliminary to the steps in figure 3, the 
5 smtp/pop e-mail system and the e-mail processors have communicated to the 
ISDA/alidator that e-mail has been received and is available for processing. 



Generally, at step 50, the ISDA/alidator searches the e-mail for a rich 
media file (e.g. html code). Rich media is a media type such as JPEG, 

io GIF/animated GIF, Enliven. InterVU. Comet Cursors, VRML. Shockwave, and 
Flash. If a rich media file is found, then at step 54 a rich media advertisement 
is created. At step 56, all creative assets (e.g. rich media) referred to within 
the html file are retrieved. The creative assets are elements that will be 
processed and combined to form an advertisement. The elements may 

is include text, images, or rich media code. If there are references to assets 
within the html file, then the assets are saved to a database and under a 
specific directory, steps 58 and 60. If there are no assets present within the 
html file, then the html file bypasses step 60 and goes directly to step 62. At 
step 62, the html (e.g. rich media) filter parameters are retrieved from the 

20 database. The filter parameters represent selections made by the user at the 
front-end of the system. If there are any html filters enabled, step 64. then the 
html file is stored in its original format as a backup file, step 66 At step 68. 
the html filters that are enabled are constructed so that they may be applied to 
the html file. The html file is scanned through the enabled filters, step 70, and 
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the resulting filtered html file is stored in the database, step 72. If there are no 
enabled filters, step 64, then steps 66, 68, 70, and 72 are bypassed. At step 
74, the properties (e.g. file size) of the html file are retrieved by scanning the 
file and storing the results in the database. At step 76, ad model parameters 

5 are retrieved from the database. The ad model parameters represent Web 
site guidelines for displaying advertisements. In step 80, if ad models are 
found within the database, step 78, then the properties retrieved in step 74 
are compared to ad model parameters retrieved in step 76. The ad model 
parameters that match the html properties are identified and stored in the 

10 database, step 82. If no ad models are located, in step 78, then steps 80 and 
82 are bypassed. At step 84, the status of the html file is changed to M new" 
and the file is ready for processing by the front-end of the system. 

More specifically, at step 50 of Figure 2, the ISDA/alidator system 
is searches the e-mail for any attachments that contain files with html 

extensions. If html files are not found, then the html processing ends and 
processing for image files, text files, and unknown files begin, step 52. If html 
files are found, then an html advertisement is created, step 54. Creating an 
html advertisement, step 54, involves creating a record for the html file in the 
20 database. The record is given a unique identification code and any 

references to the html file are by its identification code. Additionally, any files 
related to the html file will also be stored in reference to the identification 
code. 
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At step 56, the html file is parsed for all creative assets referred to 
within the html file. The creative assets are elements that will be processed 
and combined to form the advertisement. The elements may include text, 
images, or rich media code. The ISD/Validator system parses the html file by 
5 reviewing the html file for any assets located within the html file. The 
ISD/Validator system searches for anything that refers to another file that 
would become an element in the display of an html screen. This is achieved 
by searching the html file for tags that reference image files. An example of 
the types of tags that the ISD/Validator system searches for are "Source =" 

io and "code =" tags. Attached to the tag is a file name, under which the image 
file can be located. The different types of html tags that the ISD/ Validator 
system searches for are GIF. JPEG. AU, AUI. Class files, and Shockwave 
files. Next, the ISDA/alidator system searches all the attachments within the 
e-mail for the assets identified during the parsing of the html file. This is 

is achieved by comparing the list of file names of the assets (found during 
parsing) to the attachments that are part of the e-mail. If assets are found, 
then they are removed from the e-mail attachment list and stored in the 
database under a specific directory. If there are references to assets within 
the html file, step 58. then the assets are stored in the database and moved to 

20 a specific directory, step 60. 



Once step 56 is completed and the number of referenced assets are 
stored, the assets are then grouped. The assets, referred to within the html 
file, are grouped into image assets, text assets, and/or unknown assets. The 
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names of these assets are marked as being part of the advertisement and 
stored in the database under the appropriate heading. If there are no 
references to assets within the html file, step 58, then step 60 is bypassed. 

5 At step 62 of Figure 2, the ISD/Validator system retrieves html (rich 

media) filter parameter names and values from the database and stores them 
in program memory. The filter parameter names and values reflect filter 
selections made at the front-end of the system by the user. Different filter 
parameter names and values make up combination filters. In order that the 

kj filters reflect the current status of enabled and disabled filter selections made 
at the front-end of the system, the filter parameters are retrieved from the 
database each time they are needed. If any html (rich media) filters are 
enabled, then the original html file is stored as a backup file in the database, 
steps 64 and 66. In step 68. the html filter is constructed. This requires 

is retrieving atomic filters from the database and combining them to form the 
combination filters that were enabled in the front-end of the system. 

At step 70 of Figure 2, the html file is applied to each of the 
combination filters that are defined in the front-end of the system. This is 
20 achieved by scanning through the html file character-by-character and/or line- 
by-line and comparing the characters and/or lines to the filters. If there is a 
match, then the filter is applied. The result is a new (modified) html file with all 
of the html filters applied, which may include insertions in the html file and/or 
deletions from the html file. At step 70, the new html file, is stored in the 
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database where it can be retrieved for further processing. If there are no html 
(rich media) filters enabled, step 64, then steps 66, 68, 70, and 72 are 
bypassed and the process continues with the original html file. 

5 In step 74, properties of the new html file are determined and stored in 

the database. The properties are determined by scanning the new html file 
for file size, total number of lines, total number of characters, total number 
referred images in the html, list of all files referred in the html, total file size of 
all image files referred in the html, and existence of any references to Java or 
io JavaScript. 

In step 76. ad model parameters are retrieved from the database and 
stored in memory. The ad model parameters represent Web site guidelines 
for displaying advertisements. Because the parameters are set by the user at 

is the front-end of the system and may be changed, the parameters are 

retrieved from a common database to reflect the current selection of the user 
and thus reflect the current ad model parameters. As a result, every time this 
function is performed, the rules are retrieved from the database in case some 
of the rules have been changed. The ad models are predetermined 

20 parameters that reflect particular standards or rules for placing an ad on a 
Web page. These rules include, but are not limited to, maximum file size, 
maximum lines, maximum characters, maximum images, allow Java, and 
allow JavaScript. The ad model parameters are set by the user at the front- 
end of the system. 
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If there are ad models in the database, step 78 of Figure 2, then the 
properties of the new html file are compared to all of the ad model 
parameters, step 80. If the new html file properties do not match any ad 
model parameters, then a warning string is constructed and stored in the 
s database, step 80, and the warning string is noted as a warning status at the 
front-end of the system for the user to identify. If the new html file properties 
match one or more ad models, then an acceptance string is constructed and 
an acceptance status is noted at the front-end of the system for the user to 
identify and the acceptance string is stored in the database, step 80. With the 
io status of the html file (advertisement) changed to new. step 84, the 

advertisement is ready for processing in the front-end of the system. The 
advertisement is displayed at the front-end of the system for visual inspection 
by the user. Once inspected, the user can assign the advertisement to a 
campaign and an advertiser. 

15 

The present invention provides the advertisement management system 
user the ability to select and create rich media filters to modify the rich media 
code in preparation for display on a web site. The user has the option to 
initiate a number of filters that may insert, delete, or update portions of the 
20 code to allow for proper display of the advertisement over the Web. There are 
two types of filters used in this system, standard filters and user defined filters. 
Standard filters are used to remove html header tags. Examples of standard 
filters include, but are not limited to: remove <head> tag, remove <html> tag, 
remove <meta> tag, remove <body> tag. These tags are part of a standard 
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web page and are also included in the creative assets submitted by the 
advertiser or advertising agency to the advertisement management system. 
However, because the creative asset (html file) is being placed within a web 
page that already includes the standard tags, the tags associated with the 
s creative assets are not needed and are removed by the filtering process. 

Another type of standard filter is an insert redirect string The insert 
redirect string filter inserts a redirect string everywhere there is a <href> tag in 
the html file. Normally, when a creative asset (html file) is received from an 

10 agency it includes a URL link within the html file. The URL link is used to link 
a person who selects the advertisement to the web page of the advertiser 
(e.g. "clicking" on the advertisement to receive additional information), tn 
order to track and count the number of viewers who actually go to an 
advertiser's web page, a redirect string is inserted into the html file that 

is redirects the viewer to a tracking program, before actually going to the 

advertiser's web page. The tracking program tracks and counts the number 
of viewers who actually go through the advertisement to the advertiser's web 
page. Applying the insert redirect string filter results in a new URL (within the 
html file) that takes the viewer to a tracking program before taking the viewer 

20 to the original URL. 

User defined filters are fitters that the user creates by defining certain 
available parameters. The parameters that are available in this system are 
various types of delete and insert parameters. "Delete Tags Only" is a user 
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defined filter where the user enters start and end tags, such as <a> and </a>, 
to be removed from the code, leaving the text between the tags in the file. 
"Delete Tags And Text Between Tags" allows the user to enter start and end 
tags that identify a section of code to be removed from a file. The text 

5 between the tags, as well as the tags, are deleted. "Delete Text" permits the 
♦ 

user to select text to be deleted from a file. "Insert Text After allows the user 
to enter text that is used to flag the insertion point for text to be entered into 
the file, and the new text is entered after the text flag. "Insert Text Before" 
performs a similar function as the "Insert Text After function, except that the 

10 new text is inserted before the text flag. "Replace Text" allows the user to 
enter text to be searched for within the file and then replaces the text with 
user selected text. "Replace Text Between Tags" permit the user to enter 
start and end tags that identify a section of code to be searched, as well as 
the text to be searched and the replacement text. "Replace Text Between 

is Tags And Tags" offers the user a similar option as "Replace Text Between 
Tags" except both the searched for text and the tags are replaced with the 
new text. Numerous search and replace operations can be created from the 
above listed parameter names. 

20 The user configures the filters at the front-end of the system by 

enabling and disabling the filters of choice and then applying them to the html 
files. After the filters are defined in the front-end, they are applied to the 
back-end of the system where they are stored in the database. The back-end 
searches through the database to determine what filters are defined (enabled) 
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in the front end of the system. It then applies the filters to all of the html files 
that were stored in the database. 



Figure 3 illustrates in more detail the process of constructing rich media 
5 (html) filters. At step 90, all enabled filters, standard and user defined, are 
retrieved. If there are no enabled filters, then the filtering process stops, step 
92. If there is at least one enabled filter, step 92, then every atomic filter type 
related to the enabled filters are retrieved from the database, step 94, and 
stored in memory. At step 96, all parameters relating to each atomic filter are 

io fetched from the database and stored in memory. At step 98, the atomic 
filters are then constructed. At step 100, combination filters are constructed 
out of the atomic filters. If there are more combination filters, step 101, then 
go back to step 96 and fetch all parameters relating to each atomic filter. If 
there are no more combination filters, step 101, then construct a filter chain, 

is step 102. At step 104, the html file is retrieved from the database and stored 
in memory. At step 106, each combination filter is sequentially applied to the 
html file. If no errors are detected during step 106, then the results of step 
106 are stored in the database. If an error is detected then the filtering 
process stops and a error string is created. 

20 

More specifically, at step 90, the ISDA/alidator system retrieves all 
enabled standard and predefined filter parameters from the database and 
stores them in memory. If there are no enabled filters, then the filtering 
process ends, step 92. If there is at least one enabled filter, step 92, then 
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each atomic filter type that is related to the enabled filters is retrieved and 
store in memory, step 94. The combination filters are made of atomic filters, 
and the combination filters represent the filters that the user selects or creates 
at the front-end of the system. Examples of atomic filters are insert filter. 
5 replace filter, delete filter, and undelete filter. These filters can be combined 
in various ways to produce different combination filters. 

At step 96, the parameters for each atomic filter are fetched from the 
database and stored in memory. The parameters are further categorized as 
io parameter names and values. There are various parameters to each atomic 
filter. Examples of the parameter names are start pattern, end pattern, 
pattern to search, and pattern to apply. Not every parameter name is used in 
an atomic filter, and each filter may use different combinations of parameters. 

is At step 98 of Figure 3, the atomic filters are constructed by retrieving 

the atomic filter parameter names and values from the database. The 
parameters are constructed into an array and saved in memory. Retrieving 
the parameters from the database and constructing them when needed, 
guarantees that the atomic filters represent the current enabled filters selected 

20 by the user at the front-end of the system. 

At step 100, the html (rich media) filters are constructed by retrieving 
the atomic filters, that were constructed in step 98, from memory. The atomic 
filters are constructed into an array and saved in memory as a combination 
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filter. If there are more enabled filters in the front end, step 101 , then repeat 
steps 96, 98, 100, and 101. If there are no enabled filters, step 101 , then 
construct a filter chain, step 102. At step 102. each of the combination filters 
constructed in step 100 are chained together so that each of them can be 

5 sequentially applied to the html file. At step 104, the filters are ready to be 
applied to the html file. The html file is retrieved from the database and stored 
in memory. At step 106, each combination filter is sequentially applied to the 
html file. The html file is searched for each atomic parameter value and 
marked with each corresponding atomic parameter name. The result is a list 

io of marks within the html file that represent the atomic filter parameter names 
and values, which represent the combination filter. After the last atomic filter 
is marked within the html file, the combination filter is applied to the file. This 
results in the html file being modified to represent the filter choice made at the 
front-end of the system. This process continues until the last combination 

15 filter in the chain is applied. At step 108, if an error is detected, then the 
filtering process stops and a error string is created. If no errors are detected, 
then the results of step 106 are stored in the database, step 110. 

Figure 4 illustrates the front-end of the pick-up URL process. The pick- 
20 up URL processes html files (images) retrieved from a web site and adds 
them to existing submissions. At step 120, the user enters a URL into the 
front-end system, using the browser, and the system automatically opens the 
web site of the particular URL. The web site is loaded into the browser so that 
the user can view it. At step 122, the user selects html files (creative assets) 
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from a list of html files that are displayed within the web site. At step 124, the 
selected files are saved into a file system and the list of html files are 
displayed. At step 126, the list of html files that the user selected in step 122 
and a submission identification (id) code are sent to the back-end system for 

5 validating by the ISDA/alidator system. The list of files and the id code are 
sent in the form of a string to the back-end, and a message is sent from the 
back-end to the front-end indicating that the string was properly received. 
After validating, a status message is sent by the back-end to the front-end 
which is displayed as either success or failure, step 128. When the user 

10 closes the automatic pick-up URL browser, it displays the submission with an 
updated list of assets (images). 



Figure 5 illustrates the back-end of the pick-up URL process. 

Preliminary to step 130, the back-end receives the message sent by the front- 
is end containing the string of html files and the id code. At step 130, the string 

is separated into separate strings so that each string is an individual file. At 

step 132, the corresponding e-mail information (html files) is updated in the 

database with the new files retrieved by the front-end pick-up URL process. 

The new html files are associated with other related html files sharing the 
20 same submission identification code and stored together in the database. 

Steps 134 and 136 are described in detail in figures 2 and 3 along with the 

supporting written description. 
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It will be appreciated that changes and modifications are likely to occur 
to those skilled in the art, and it is intended in the appended claims to cover all 
those changes and modifications which fall within the sprit and scope of the 
present invention. 
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We claim: 

1 . A method for processing submissions, using a computer, 
comprising the steps of: 

a. receiving a submission; 
5 b. searching the submission for a creative asset; 

c. removing unnecessary code, attachments, or user 
selected code from the creative asset so that a modified creative asset exists 
in a form appropriate for use on a web page; and 

d. comparing for conformity, properties of the modified 
io creative asset to web site guidelines. 

2. The method of claim 1 , further comprising the step of displaying 
the modified creative asset for visual inspection. 

15 3. The method of claim 1 , further comprising the step of playing the 

modified creative asset for audible inspection. 

4. The method of claim 1 , further comprising the step of sending 
the modified creative asset to an ad server in preparation for distribution of the 

20 modified creative asset on a Web page. 

5. The method of claim 1 , wherein the submission may include 
multiple file attachments, html code, and information about where to locate a 
creative asset on the World Wide Web. 
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6. The method of claim 1 , wherein the creative asset may be text 
code, image code, and rich media code. 



7. The method of claim 6, wherein the rich media code may be 
JPEG, GIF, animated GIF, Enliven, InterVU, Comet Cursors, VRML, 
Shockwave, and Flash. 

8. A system for processing submissions, on a computer system, 
comprising: 

a front-end system for providing user control of the system; 

a mail system for receiving, transmitting, and processing submissions 
into creative assets; and 

a business system coupled to the front-end system and the mail 
system, wherein the business system receives creative assets and applies 
filters to creative assets, resulting in modified creative assets that are 
compared to ad models. 

9. The system of claim 8, further comprising a database coupled to 
the computer for providing storage of rich media files, filters, and ad models. 

10. The system of claim 9, further comprising an ad server 
database for storing submissions for use by a web site. 
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1 1 . The system of claim 10, further comprising an adapter for 
interfacing the database with the ad server database. 



12. The system of claim 8, wherein creative assets may be text 
5 code, image code, and rich media code. 

13. The system of claim 12, wherein the rich media code may be 
JPEG, GIF, animated GIF, Enliven, InterVU, Comet Cursors, VRML, 
Shockwave, and Flash. 

io 

14. The system of claim 8, wherein the mail system further comprises 
a smtp system for receiving and transmitting e-mail. 

15. The system of claim 8, wherein the mail system further comprises 
is a POP system for receiving and transmitting e-mail. 

16. The system of claim 8, wherein the mail system further 
comprises mail processors for separating the submission into components 
that may contain multiple file attachments, html code, or text that includes 

20 information about where to find creative assets on the World Wide Web. 

17. The system of claim 8, wherein the filters remove unwanted 
code and add required code to the creative asset. 
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The system of claim 8, wherein the ad models are web site 



19. The system of claim 8, wherein the front-end system further 

5 comprises a pick-up URL system for locating submissions on the world wide 
web. 

20. The system of claim 8, wherein the front-end system comprises 
at least one web browser system for viewing data and controlling data from a 

io web server, where the web server provides the interface between the 
business system program and the web browser. 

21 . A computer implemented method for processing a submission 

received over a computer network comprising the steps of: 

15 a. searching the submission for an attachment that contains a first 

« 

rich media file; 

b. creating a record for the first rich media file wherein the first rich 
media file is assigned an identification code; 

c. parsing the first rich media file for a rich media file name referred 

20 within; 

d. searching the submission for a second rich media file associated 
with the rich media file name identified during parsing; 

e. storing the first rich media file and the second rich media file; 

f. retrieving filter parameters from a database; 
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g. constructing filters; 

h. applying the filters to the first rich media file so that a modified 
rich media file exists; 

i. storing the modified rich media file; 

j. assessing properties of the modified rich media file; 
k. retrieving ad model parameters; and 
I. checking the modified rich media file for compliance with ad 
model parameters. 

22. The method of claim 21 , wherein the rich media file is a hyper 
text markup language file. 

23. The method of claim 21 , further comprising before step (a), a 
step of receiving a submission. 

24. The method of claim 21 , wherein step (c) the first rich media file 
is searched for rich media file tags that reference image files. 

25. The method of claim 24, wherein the rich media file tags are 
GIF, Animated GIF, JPEG, AU, AUI, InterVU, Comet Cursors, VRML, Class 
files, Flash, and Shockwave. 

26. The method of claim 21, wherein step (g) further comprises the 
steps of combining filter parameters to form a filter. 
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27. A method of retrieving creative assets from a web site and 
adding them to existing submissions stored in a database comprising the 
steps of: 

a. selecting a URL; 
5 b. accessing the URL web site; 

c. selecting creative assets from a list of files displayed at the web 

site; 

d. storing the selected files in the database; and 

e. attaching an identification code to the list of the selected files. 

10 

28. A computer system comprising: 

a front-end system, wherein the front-end system provides a user with a 
window and controls through which one or more creative assets can be 
reviewed, and where the user can enable one or more filters and enable one or 
is more ad models to apply to one or more creative assets; and 

a back-end system, coupled to the front-end system, wherein the back- 
end system applies one or more filters to one or more creative assets resulting in 
one or more modified creative assets, and determines whether one or more 
modified creative assets conform with one or more ad models. 

20 

29. The computer system of claim 28, wherein the back-end system 
further comprises an email server, coupled to the Internet, for receiving one or 
more creative assets and for sending one or more modified creative assets to a 
third party. 
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30. The computer system of claim 28, wherein one or more creative 
assets are reviewed for content by the user. 



31. The computer system of claim 28, wherein the back-end system, 
5 having Internet capabilities, locates one or more creative assets using a Uniform 

Resource Locator selected by the user and where the user selects one or more 
creative assets to be retrieved by the front-end system. 

32. The computer system of claim 28, wherein the back-end system 
id determines whether one or more modified creative assets conform with one or 

more ad models, by determining properties of one or more modified creative 
assets and verifying the properties against ad models. 

33. The computer system of claim 32 wherein the ad models comprise of 
15 web site guidelines for displaying advertisements. 

34. A system for processing a submission comprising: 

a front-end system for providing an interface to the system for a user; and 
a back-end system, coupled to the front-end system, for applying filters 
20 to the submission, determining properties of the submission, and applying ad 

model parameters to the submission to determine whether the submission 

complies with web site guidelines. 
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The system of claim 34 wherein the submission further comprises 



36. The system of claim 34 wherein the submission further comprises one 
5 or more attachments. 

37. A computer implemented method for processing one or more creative 
assets comprising the steps of: 

filtering one or more creative assets to produce one or more modified 
io creative assets; 

determining properties of one or more creative assets; and 
o comparing properties of one or more creative assets to one or more ad 
model parameters to determine compliance. 

15 38. The method of claim 37 further comprising, before the step of filtering, 

the steps of: 

retrieving filter parameters; and 
constructing filters from the filter parameters. 

20 39. The method of claim 37 further comprising, before the filtering step, 

the step of: 

searching a submission for one or more creative asset; and 

retrieving one or more creative assets referred to within the submission. 
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40. The method of claim 37 further comprising the step of reviewing one 
or more modified rich media files for content. 



41 . The method of claim 37 wherein the ad model parameters comprise 
5 of web site guidelines for displaying advertisements. 



42. A computer implemented method for processing a submission 
comprising the steps of: 

searching the submission for one or more html files; 
io parsing one or more html files for one or more creative assets referred to 

within the html file; 

searching the submission for one or more creative assets referred to 
within one or more of the html files; 

filtering one or more creative assets; 
is determining properties of one or more creative assets; and 

determining whether one or more creative assets comply with one or 
more ad model parameters. 



43. The method of claim 42 wherein the parsing step further 

20 comprises the step of searching the html file for tags that reference image 
files. 

44. The method of claim 42 wherein the step of determining whether 
one or more creative assets comply with one or more ad model parameters 
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further comprises the step of comparing one or more creative asset properties to 
one or more ad model parameters. 



45. The method of claim 42 further comprising the step of generating an 
5 acceptance status of one or more creative assets, if properties of one or more 
creative assets comply with ad model parameters. 
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